Should use copy of remotes.listenerTree? - #1966
Conversation
|
Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test." |
|
@slnode ok to test |
|
Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test." |
|
Hi @timneedham, thank you for the pull request. Could you please add a unit-test to reproduce the problem and verify that your change fixed it? |
|
Hi @bajtos, I think I've hit my current ceiling at the moment... I did a repo to illustrate the problem here: https://github.com/timneedham/nest-remoting-issue ...which @gunjpan confirmed in #1951 : apologies, I have tried, expressing this as a unit-test is a bit out of my grasp at the moment. Kind regards Tim |
|
Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test." |
|
@timneedham apparently this bug is not possible to reproduce in our Mocha-based test suite :( I opened a new PR to make sure nothing breaks in the current code base, and also reworded the commit message - see #2245. |
5 participants
Hi,
This is my first ever pull request (apologies if it sucks)...
As part of investigating Loopback issue #1951 with @gunjpan's assitance (whereby creating models/relations programatically appears to cause
model.nestRemoting()to throw a TypeError in the absence of a remotes listenerTree) I think I found something here:https://github.com/strongloop/loopback/blob/master/lib/model.js#L805-L810
remotes.listenerTree, which has been defaulted to handle the absence of alistenerTree, but shortly-after the original un-defaulted value is used, and not the local copy. That's when I hit theTypeError.A quick change to use the local copy (as per the PR) fixes the immediate issues I was facing in #1951.
Hope this helps?
Tim